json spec doesn't pose any limit to the number of bits for the number type (https://www.json.org/json-en.html).

As u128 is native to Rust and thus doesn't really need bignum support. I propose to:

1. accept this
2. (optional) propose a serde_json patch to exten numbers to u128.

However, I also understand @koute perplexities, i.e. popular libs and other lang implementations typically support up to u64

Hmm.... as an alternative maybe we should consider serializing those numbers as strings instead, if possible?

The reason being that this is not really portable, so anyone who will try to load a JSON containing such numbers in any other language, using any other library, or just using serde_json without this flag will silently get incorrect results (if the library doesn't explicitly produce an error in such case, and I think almost all of them don't?).

Would that means that also 64-bit integers would need to be serialized as String? (https://www.rfc-editor.org/rfc/rfc8259#section-6):

Note that when such software is used, numbers that are integers and
are in the range [-(2^53)+1, (2^53)-1] are interoperable in the
sense that implementations will agree exactly on their numeric
values.

This for sure needs to be solved at some point. Strings would be possible, but that would require touching affected pallets.

json spec doesn't pose any limit to the number of bits for the number type (https://www.json.org/json-en.html).

As u128 is native to Rust and thus doesn't really need bignum support. I propose to:

1. accept this
2. (optional) propose a serde_json patch to exten numbers to u128.

However, I also understand @koute perplexities, i.e. popular libs and other lang implementations typically support up to u64

See discussion here: serde-rs/json#846

FWIS actually serde_json does not support u128 :), that is why we need arbitrary precision.

Would that means that also 64-bit integers would need to be serialized as String?

For perfect compatibility with everything, yes. (In languages where numbers are f64 there's only 52 bits of mantissa, so you can't encode full 64-bit ints with full precision.)

It is an open question whether we care, but it is a footgun that should be at the very least documented.

It is an open question whether we care, but it is a footgun that should be at the very least documented.

You mean that other languages would fail to parse such a number?

It is an open question whether we care, but it is a footgun that should be at the very least documented.

You mean that other languages would fail to parse such a number?

It's matter of json lib implementation. Some will do (ruby,python), some not (nodejs). From what I found this c++ json lib nlohmann/json is not able to parse it.